home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19950726-19950929
/
000349_news@columbia.edu_Tue Sep 12 01:53:02 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-12-25
|
5KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA06219
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Tue, 12 Sep 1995 12:27:22 -0400
Received: by apakabar.cc.columbia.edu id AA19073
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Tue, 12 Sep 1995 12:26:50 -0400
Path: news.columbia.edu!panix!news.mathworks.com!tank.news.pipex.net!pipex!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS-KERMIT 3.14 hanging on idle TCP/IP connection?
Message-Id: <1995Sep12.075302.61110@cc.usu.edu>
Date: 12 Sep 95 07:53:02 MDT
References: <42d2u9$edt@apakabar.cc.columbia.edu> <433mrn$49i@apakabar.cc.columbia.edu>
Organization: Utah State University
Lines: 84
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <433mrn$49i@apakabar.cc.columbia.edu>, chaiklin@merhaba.cc.columbia.edu (Seth Chaiklin) writes:
> In article <2979@sun3.ipswitch.com>, Dan Lanciani <ddl@harvard.edu> wrote:
>
> [stuff deleted about how a MSK machine would lose control of the
> terminal output after about 10 minutes and the ARP cache on a Linux
> (1.2.8) machine would lose the hardware address of the MSK machine. ]
>
>>You'd need a network trace to be sure, but this suggests that kermit
>>isn't responding to ARPs in its current state.
>
> I have traceroute and netstat (and maybe some others) on the Linux box.
> It was mentioned that this could be helpful, but I do not know what I should
> do or what I should look for.
>
>>There are at least two additional experiments that might shed light on
>>the situation.
>>First, while in the bad state, try to ping it from another machine that
>>has never been involved with the connection at all. This should tell
>>you whether kermit is willing to respond to anybody's ARP at this point.
>
> I did try this, and the MSK machine responded to the ping, so there was no
> need to try the second test.
>
> I also tried to ping from the Linux box, but there was no response.
> However, if I handloaded the Hardware address of the ethernet
> card on the MSK machine, then I could get a ping response.
>
> However, this handloading technique does not always result in control being
> returned to the MSK machine, as I once reported.
>
> Meanwhile, some more information. After the MSK machine would not
> respond (this again means, no output on the screen. It is still possible
> to shell out to DOS, issue commands to the Linux box (as confirmed with a
> 'w' command from the console) etc., etc.), I tried to telnet to the same
> Linux machine as well as other machines. I got the error message:
> Unable to ARP resolve gateway
>
> This was when I tried to ping from the Linux machine (with no response).
This rather clearly indicates that the Linux TCP/IP stack has real
problems with its ARP cache and destination MAC address handling.
> I tried another experiment. I logged in from the MSK machine, then immediately
> deleted the entry from the Linux ARP cache. The output stopped, as other
> times. It was still possible to telnet to other machines, but now it was
> impossible to telnet to the Linux machine, no error message or anything, just
> a return to the Kermit prompt.
Ditto.
> Finally, I hand-entered the hw address for the MSK machine, and now I have
> tried two or three times to let the MSK machine sit for for 30-60 minutes,
> and I have not been able to reproduce the problem. It sounds like I
> should just try to load the addresses for these cards, maybe even as a
> cron job...but I would still like to try to understand what is going wrong.
>
> I noticed in a recent message that there was an updated version of Kermit.
> I use a version from 18 Jan 95. Could this also be a possible source of the
> problem?
Not that I can deduce.
> So I put a copy of 21 May 1995 onto the MSK machine. Tried to connect to
> the Linux box and got: Unable to ARP resolve xxx.yyy.xxx.zzz
> However, I was able to telnet to other machines.
>
> Aaarrgh! I am really interested in solving this problem because we
> would like to use 8-bit characters, and other telnet programs do not
> behave as well as Kermit about this.
How about talking to the Linux News groups for hints. You are not
the only person to report such problems.
> Also, when these "freeze-ups" do happen, it does not seem proper that
> MS-Kermit should lockup on "exit" or "hangup" requiring a power-down
> to restart the machine. I just wanted to re-emphasize that point.
If MSK sends a TCP segment which requires an acknowledgment from
the other end then it must wait and wait for it, and finally give up after
a long interval. The process of tearing down a connection does the same
(tries a proper FIN close, then if necessary sends an RST and bails out,
but the FIN close has time delays. Unack'd data requires waiting, and
FIN, and waiting...).
Joe D.